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Abstract 

Many  large  organizations  today  are  finding  that  even  if  they  can  access  data  from  multiple 
functions,  the  lack  of  logical  data  integration  (common  data  definitions  and  codes)  across 
information  systems  makes  it  difficult  or  impossible  to  answer  cross-functional  or  cross- 
divisional  questions.  This  reduces  their  ability  to  take  advantage  of  potential  opportunities 
or  respond  to  business  problems.  Strategic  Data  Planning  is  one  methodology  which  can 
address  such  problems,  within  the  general  umbrella  of  information  engineering.  Resting  on 
the  assumption  that  a  relatively  stable  group  of  data  entities  lies  at  the  center  of  an 
organization's  information  processing  needs,  SDP  is  a  formalized,  top-down,  data-centered 
planning  approach  that  builds  a  model  of  the  enterprise,  its  functions,  and  its  underlying  data 
as  a  basis  for  identifying  and  implementing  an  integrated  set  of  information  systems. 

In  spite  of  strong  conceptual  arguments  for  the  value  of  the  SDP  approach  and  its  use  in 
many  organizations,  empirical  researchers  have  failed  to  find  clear-cut  evidence  of  its  general 
success.  This  raises  the  question  of  whether  the  approach  is  universally  appropriate.  If 
success  is  somewhat  problematic,  are  there  lessons  that  can  be  drawn  from  actual 
organizational  experience?  The  purpose  of  this  paper  is  to  report  the  results  of  a  series  of 
case  studies  of  SDP  efforts,  to  offer  insights  on  the  conditions  under  which  SDP  is  most 
effective,  and  to  propose  directions  for  future  research. 


INTRODUCTION 

Among  many  managers,  there  is  an  increased  appreciation  for  the  role  of  data  in 
meeting  the  challenges  of  today's  business  environment.  Access  to  data  from  various 
organizational  subsystems  is  often  required  to  respond  to  the  demands  of  an  increasingly 
competitive  global  marketplace.  Yet  many  large  organizations  today  are  finding  that  even 
if  they  can  access  data  from  multiple  functions,  the  lack  of  logical  data  integration  (common 
data  definitions  and  codes)  across  information  systems  makes  it  difficult  or  impossible  to 
answer  cross-functional  or  cross-divisional  questions.  This  reduces  their  ability  to  take 
advantage  of  potential  opportunities  or  respond  to  business  problems  (Goodhue  1989; 
Gartner  Group  1990). 

This  lack  of  logical  data  integration  is  generally  believed  to  be  a  result  of  the  way 
systems  development  has  been  conducted.  IBM  (1981)  notes  that  systems  have  typically 
been  developed  within  a  functional  area,  with  little  regard  for  how  those  systems  or  the  data 
they  use  can  be  shared  across  functional  areas  to  better  support  the  business's  information 
needs. 

Information  Engineering  and  Strategic  Data  Planning.  Information  Engineering 
(Finkelstein  1981;  Martin  1982,  1986;  Hackathorn  and  Karimi  1988)  is  a  management 
perspective  and  a  collection  of  methodologies  intended  to  address  this  problem  of 
insufficient  logical  data  integration  by  designing  systems  with  the  total  organization's 
information  needs  in  mind.  "Strategic  data  planning,"  or  SDP,  is  a  methodology  that  fits 
within  the  general  information  engineering  umbrella,  addressing  two  critical  phases  of 
information  engineering  (Hackathorn  and  Karimi  1988):  organizational  analysis,  and  the 
strategy-to-requirements  transformation. 

SDP  and  information  engineering  are  based  on  the  assumption  that  a  relatively  stable 
group  of  data  entities  lies  at  the  center  of  an  organization's  information  processing  needs. 
SDP  is  a  formalized,  top-down,  data-centered  planning  approach  that  builds  a  model  of  the 
enterprise,  its  functions,  processes,  and  its  underlying  data  as  a  basis  for  identifying  and 
implementing  an  integrated  set  of  information  systems  that  will  meet  the  needs  of  the 
business.  Sidebar  #1  describes  the  general  SDP  methodology.  The  SDP  approach  can  be 


Though  there  are  differences  between  the  various  methodologies,  there  are  a  great  many  similarities. 
The  participants  in  an  SDP  should  always  include  business  personnel  (users)  and  may  include  IS 
personnel.  Getting  the  right  participants  is  critical  to  the  quality  of  the  final  product  The  planning 
team  is  charged  with  designing  an  "ideal"  information  environment  that  will  support  current  and  future 
business  needs  regardless  of  a  particular  organization  structure.  The  process  involves  at  least  the 
following  steps: 

First,  an  enterprise  model  of  the  organization  is  developed,  consisting  of  an  identification  of 
the  business  functions  (usually  10  to  30)  that  the  organization  performs,  further  broken  down 
into  processes  within  functions  (perhaps  100  to  300  processes  all  told).  These  processes  may 
be  further  broken  down  in  to  activities  within  each  process.  The  processes  or  activities  may  be 
related  to  organizational  groups  responsible  for  them. 

Second,  the  data  entities  used  by  these  various  processes  or  activities  (such  as  customer, 
purchase  order,  location,  product)  are  identified.   (There  might  be  several  hundred  or  more 
entities  used  by  a  medium  to  large  business.)  Each  of  these  entities  is  associated  with  the 
processes  or  activities  that  use  or  create  it. 

Third,  an  "affinity  analysis"  is  performed  to  identify  groups  of  entities  that  are  closely 
associated.  These  become  the  candidate  subject  databases,  which  should  be  adjusted  manually 
based  on  other  considerations. 

Fourth,  the  subject  databases  and  the  processes  which  use  or  create  that  data  are  grouped  so 
that  major  system  areas  can  be  identified. 


Often  taking  place  concurrently  with  the  above,  another  effort  documents  how  there  business 
processes  and  activities  are  currently  supported  by  existing  information  systems. 

Senior  managers  are  interviewed  to  determine  the  executive  point  of  view  including  current 
and  future  business  objectives.  This  usually  occurs  after  the  above  steps. 

These  several  efforts  come  together  to  produce  a  set  of  plans  or  architectures  that  typically 
include  a  list  of  the  organization's  recommended  subject  databases  and  major  application 
areas,  a  migration  plan  from  current  to  desired  systems,  targeted  applications,  resource 
allocation  recommendations  for  application  development,  and  guidelines  concerning  standards 
(hardware,  software,  and  data). 


distinguished  from  other  information  systems  planning  methodologies  by  its  focus  on  defining 
the  underlying  shared  data  used  by  the  organization's  many  functions,  and  by  the  definition 
of  a  "data  architecture"  to  guide  future  systems  development  efforts  (Lederer  and  Sethi 
1988).  Two  examples  of  the  approach  are  James  Martin's  (1982)  Strategic  Data  Planning 
and  the  older  Business  Systems  Planning  (BSP)  developed  by  IBM  (1981). 

How  Successful  Is  Strategic  Data  Planning?  In  spite  of  strong  conceptual  arguments 
for  the  value  of  the  SDP  approach  (e.g.,  Martin  1982;  Appleton  1983;  Kanter  and 
Miserendino  1987)  and  its  use  in  many  organizations,  empirical  researchers  (e.g.,  Lederer 
and  Sethi  1988;  Goodhue  et  al.  1988)  have  failed  to  find  clear-cut  evidence  of  its  general 
success. 

Lederer  and  Sethi  (1988)  surveyed  80  IS  executives  from  medium  and  large 
organizations  involved  in  IS  planning  (predominantly  SDP  methodologies).  The  respondents 
indicated  moderate  dissatisfaction  with  the  resource  requirements,  and  high  dissatisfaction 
with  the  final  execution  of  the  plans.  The  two  most  critical  problems  in  final  execution  of 
SDP  plans  were  found  to  be:  difficulty  in  obtaining  top  management  commitment  for 
implementing  the  plan,  and  lack  of  sufficient  detail  to  implement  the  plan.  The  authors 
suggest  that  organizations  may  commit  insufficient  resources  to  complete  and  implement 
their  plans. 

While  conducting  31  case  studies  on  data  management  approaches,  Goodhue  et  al. 
(1988)  found  five  cases  of  SDP.  None  of  these  was  completely  successful,  and  three  of  the 
five  were  discarded  without  being  implemented.  They  observe  that  "for  many  firms,  the 
approach  is  too  expensive,  its  benefits  are  too  uncertain,  and  it  is  organizationally  difficult 
to  implement"  (p.  383).  They  also  noted  that:  SDP  requires  key  managers  to  commit 
substantial  time  and  effort;  the  business  may  change  during  the  long  planning  process;  and 
the  specific  product  of  the  SDP  effort  is  not  always  articulated,  making  it  difficult  to  manage 
the  expectations  of  both  participants  and  top  management.  See  Sidebar  #2  for  the 
complete  table,  "Reasons  Why  Strategic  Data  Planning  Approaches  are  Difficult  to 
Implement",  from  Goodhue  et  al.  (1988). 

Based  on  fifteen  case  studies  of  firms  which  rate  themselves  as  effective  planners, 
Sullivan  (1985)  argues  that  the  appropriate  planning  methodology  depends  on  the  degree 


Sidebar  #2.  Why  Strategic  Data  Planning  Approaches 
are  Difficult  to  Implement 


The  strategic  data  planning  process,  done  in  detail  and  with  a  wide  scope,  can  be  very  time 
consuming  and  expensive.  For  the  process  to  be  successful,  key  operating  managers  must 
commit  significant  time  and  effort  This  commitment  is  often  difficult  to  obtain  (and  keep) 
from  these  busy  individuals. 

Because  of  the  up-front  effort  needed,  organizations  face  a  longer  and  more  expensive 
development  process  for  the  initial  systems  developed  with  data  planning  methods.  Line 
managers  do  not  like  to  see  project  schedules  lengthened.  Similarly,  I/S  managers,  who  have 
incentives  to  deliver  quickly  and  contain  costs,  may  resist  the  additional  effort  involved. 

The  methodologies  require  new  I/S  skills  and,  therefore,  may  not  be  easily  adopted  by  I/S 
personnel. 

Often  the  business  will  change  while  the  plan  is  being  developed  and  implemented. 

Total  implementation  of  a  wide-scope  data  planning  effort  can  be  extremely  expensive.  There 
is  a  tendency  to  avoid  these  new  costs,  especially  if  many  of  the  existing  systems  (which 
represent  a  huge  investment)  are  still  effective. 

When  implementing  only  a  subset  of  the  plan,  it  can  be  difficult  to  bridge  the  gap  from  the 
top-down  plan  to  bottom-up  design.   If  proposed  and  existing  systems  interface  along  different 
boundaries,  it  may  be  hard  to  isolate  and  replace  a  subset  of  existing  systems  with  a  subset  of 
proposed  systems.  The  use  of  application  packages  also  creates  interface  and  boundary 
problems. 

It  is  not  always  clear  to  the  planners  or  top  management  whether  a  strategic  data  model  is 
being  developed  to  produce  a  systems  plan,  create  an  architecture,  or  to  design  new  databases. 
It  is  difficult  to  manage  the  expectations  of  those  involved  regarding  the  results  and  benefits  of 
the  process. 


Source:  "Managing  the  Data  Resource:  A  Contingency  Perspective,"  MIS  Quarterly,  Vol.  12,  No.  3, 
Sept.  1988,  p.  383. 


of  IS  decentralization  (system  diffusion)  and  the  extent  to  which  technology  use  is  strategic 
(system  infusion).  For  example,  BSP  is  considered  the  right  choice  when  systems  are 
strategically  important  and  centrally  controlled. 

The  uncertain  success  record  of  SDP  suggested  by  these  studies  is  somewhat 
surprising,  given  its  conceptual  appeal  and  continued  practice.  It  raises  the  question  of 
whether  the  approach  is  universally  appropriate.  If  success  is  somewhat  problematic,  are 
there  lessons  that  can  be  drawn  from  actual  organizational  experience?  The  purpose  of  this 
paper  is  to  report  the  results  of  four  case  studies  of  SDP  efforts  that  were  conducted  as  a 
continuation  of  the  research  reported  in  Goodhue  et  al.  (1988).  The  analysis  emphasizes 
the  various  goals  a  firm  might  have  in  undertaking  a  strategic  data  planning  effort  and  offers 
insights  on  a  number  of  key  issues  that  affect  the  success  of  a  strategic  data  planning  effort. 


RESEARCH  APPROACH:  STUDYING  A  POORLY  UNDERSTOOD  PHENOMENON 

Why  Case  Studies?  It  seems  there  is  a  gap  between  the  theorizing  about  strategic 
data  planning  and  the  results  organizations  are  seeing.  When  empirical  evidence  does  not 
bear  out  our  theories,  it  may  be  that  our  mental  models  of  the  phenomena  are  missing 
critical  variables  or  critical  links  between  variables.  The  poor  success  rate  of  strategic  data 
planning  suggests  that  SDP  and  its  role  in  organizations  may  be  more  complex  than  has  been 
thought.  If  so,  researchers  may  need  to  adopt  "ambivalent  conceptual  orientations, 
ambivalent  inquiring  practices,  and  varying  positions  on  the  issues"  (Weick  1979,  p.  63)  as 
a  way  of  updating  our  mental  models. 

The  difficulty  with  research  methodologies  such  as  surveys,  when  we  know  too  little 
about  the  phenomenon  itself,  is  that  they  may  become  focused  on  the  wrong  issues  or 
variables  (Weick  1979).  For  example,  prior  surveys  of  SDP  processes  may  have  over- 
emphasized top  management  support,  ignoring  other  critical  but  as  yet  unidentified  factors. 

Case  studies,  on  the  other  hand,  provide  the  opportunity  to  elicit  the  subtle  and  rich 
data  needed  to  increase  our  understanding  (Benbasat  et  al.  1987;  Yin  1984).  Since  the  goal 
of  the  current  effort  is  to  understand  why  and  under  what  circumstances  the  SDP 
methodology  is  "successful",  case  studies  appear  to  be  the  most  appropriate  methodology. 

What  is  Success?    If  we  want  to  identify  important  nuances  which  have  a  major 

impact  on  the  success  of  SDP  efforts,  we  must  be  clear  about  what  the  possible  objectives 

and  outcomes  are  in  this  context.  From  previous  work  on  data  management  and  strategic 

data  planning1,  we  argue  that  there  are  several  distinct  outcomes  which  organizations  can 

be  trying  to  achieve  by  undertaking  a  strategic  data  planning  effort.  These  outcomes,  and 

thus  "success",  might  take  a  number  of  different  forms  including  some  combination  of  the 

following: 

1.  Totally  Integrated  Systems.  The  SDP  could  produce  a  detailed  plan  for 
a  complete  set  of  subject  databases  and  integrated  applications  across  the 


*  This  work  includes  case  study  research  by  the  Center  for  Information  Systems  Research  at  MIT,  referred 
to  in  Goodhue  et  al.  (1988),  as  well  as  additional  case  study  work  at  both  MIT  and  the  University  of 
Minnesota. 


target  domain  of  the  planning  effort,  to  be  built  in  the  near  future. 

2.  Data  Architecture.  The  term  "data  architecture"  is  often  used  but  seldom 
defined.  We  will  define  it  as  a  set  of  constraints  on  the  system  development 
process  that  insures  a  desired  level  of  data  integration  (data  definition  and 
value  consistency)  in  all  future  systems  development  or  maintenance  activities. 
A  very  high  level  data  architecture  might  be  the  identification  of  some  ten  to 
thirty  data  aggregates  (collections  of  data  entities)  around  which  future 
databases  should  be  designed.  A  more  detailed  data  architecture  might 
include  definitions  of  key  entities  and  the  relationships  between  them.  Such 
a  "data  architecture"  would  provide  a  framework  of  standards  and  guidelines 
within  which  all  new  systems  and  revisions  to  old  systems  would  be  designed, 
gradually  moving  the  firm  toward  a  set  of  integrated  applications  and 
databases. 

3.  Identifying  Systems  Priorities.  SDP  could  identify  and  prioritize  a 
selection  of  applications  to  be  built  in  the  near  future.  This  goal  might  include 
targeting  a  small  number  of  high  payoff  applications,  or  deciding  on  how  to 
allocate  resources  among  identified  projects.  For  this  goal  it  is  assumed  that 
the  bulk  of  the  existing  applications  would  remain  in  place. 

4.  Rethinking  Business  Processes.  Given  that  SDP  involves  the  identification 
of  business  processes  and  data,  there  is  a  potential  opportunity  to  rethink 
creatively  critical  business  processes,  allowing  innovation  and  streamlining  of 
some  processes,  and  possible  elimination  of  others  that  are  no  longer  essential. 

5.  Education  and  Communication.  SDP  could  foster  better  understanding  of 
the  critical  role  of  shared  data  in  the  organization,  and  the  necessity  of 
coordinating  across  organizational  groups  in  systems  and  database  design. 

These  five  possible  outcomes  are  consistent  with  planning  objectives  cited  by  earlier 
researchers.  McLean  and  Soden  (1977)  cited  IS  planning  goals  of:  improved 
communication  with  users  and  top  management,  better  allocation  of  resources,  identification 
of  IS  department  improvement  opportunities,  and  the  identification  of  new  and  higher  payoff 
applications.  Pyburn  (1983)  suggested  hardware  and  software  architecture,  identification  of 
new  IT  opportunities,  prioritization  and  evaluation  of  projects  and  resources,  and  forging  a 
link  between  IS  and  business  strategies.  Lederer  and  Sethi  (1988)  conclude  that  the  primary 
objectives  of  IS  planning  include:  improved  communication  with  users,  increased  top 
management  support,  allocation  of  resources,  identification  of  high  payback  applications,  and 


development  of  an  organization-wide  data  architecture.  Martin  (1982)  notes  that  the  goal 
of  strategic  data  planning  efforts  is  consistency  of  information  across  all  systems;  in  other 
words,  a  set  of  logically  integrated  systems. 

Research  Design.  The  approach  taken  in  this  study  was  to  reconstruct  the  history  of 
several  SDP  efforts,  from  initial  motivation  to  final  impact,  and  to  identify  relevant  factors 
which  contributed  to  the  final  impact.  Four  recently  completed  SDP  efforts  in  three 
organizations  were  studied.  The  cases  were  chosen  as  a  convenience  sample,  but  represent 
three  different  industries  and  include  private  sector  organizations  and  a  government  agency. 
Three  of  the  four  planning  efforts  were  done  at  the  department  or  division  level;  the  fourth 
was  organization-wide. 

Three  groups  of  individuals  within  each  organization  were  interviewed:  those 
responsible  for  maintaining  and  facilitating  the  planning  methodology,  those  involved  in 
individual  planning  efforts,  and  business  personnel  affected  by  the  plans.  Table  1  shows  the 
number  of  each  type  of  respondent  for  the  four  cases. 

Data  was  collected  using  a  semi-structured  interview  agenda  with  open-ended 
questions  on:  background  and  organizational  context  for  the  SDP,  the  original  motivation 
for  the  effort,  specifics  about  the  methodology  (analyses  conducted,  level  of  detail,  number 
and  type  of  individuals  involved,  time  spent),  organization  factors  affecting  the  effort,  final 
products,  and  perceptions  of  success. 

The  next  section  briefly  presents  the  four  cases.  The  descriptions  do  not  attempt  to 
tell  the  entire  story,  but  rather  they  introduce  the  organizations,  describe  the  motivations  for 
the  SDP  efforts,  present  highlights  from  the  planning  process  with  a  focus  on  the  issues 
encountered,  and  discuss  the  results. 


2 

■*The  number  of  research  sites  agrees  with  Eisenhardt's  (1989)  observation  that  four  to  ten  case  studies 
is  appropriate  during  theory-building  efforts.  She  notes  that  it  is  difficult  to  generate  theory  with  fewer  than 
four  cases,  and  difficult  to  manage  the  volume  and  complexity  of  the  information  with  more  than  ten. 

In  addition  to  the  interview  data,  we  had  access  to  videotapes  of  focus  groups  conducted  at  Ventura 
Products,  the  site  of  the  Finance  and  SSD  case  studies.  The  focus  groups  were  conducted  by  the  group 
responsible  for  the  planning  methodology  in  an  attempt  to  identify  the  problems  and  the  benefits  associated 
with  the  SDP  efforts.  The  moderator  of  the  focus  groups  asked  participants  of  planning  efforts  to  comment 
on  their  general  impression  of  the  planning  methodology,  ways  to  improve  the  methodology,  specific  problems 
they  encountered  during  the  planning  process,  and  difficulties  with  plan  implementation. 
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Table  1.  Number  of  Respondents  by  Type. 

Organization 

Individuals 
Responsible  for 
Method 

Planning 
Participants 

Individuals 
Impacted  by  Plans 

LSA 

3 

5 

5 

Ventura  Finance 

2* 

3 

1 

Ventura  SSD 

2* 

6 

2 

Cedar 

3 

2 

3 

Finance  and  SSD  are  two  units  within  one  large  organization.   In  this  organization,  there  is  one 
centralized  group  responsible  for  the  SDP  methodology.  The  same  two  individuals  from  this  group 
were  interviewed  concerning  both  the  Finance  and  SSD  planning  effort. 

THE  CASE  STUDIES:  FOUR  SHORT  HISTORIES 

Case  #1.  Logistics  and  Supply  Agency 

Background.  The  Logistics  and  Supply  Agency  (LSA)  is  a  federal  government  agency 
that  furnishes  spare  parts  and  consumables  to  other  agencies.  In  this  role,  LSA  provides  two 
major  services.  The  first  is  coordinating  the  logistics  of  shipments  between  contractors  and 
agencies;  the  second  is  contract  administration. 

LSA  employs  over  25,000  people  with  an  annual  operations  and  maintenance  budget 
of  over  $500  million,  and  an  annual  stock  fund  budget  of  over  $4  billion.  More  than  35 
groups  report  to  the  LSA  director,  who  reports  to  an  assistant  secretary  of  a  cabinet  level 
department. 

Most  of  the  information  systems  at  LSA  have  been  developed  to  address  specific  and 
sometimes  narrow  operational  needs,  and  have  not  been  developed  with  data  sharing 
between  applications  in  mind.  There  are,  however,  some  standard  systems  and  data  and  a 
single  standard  requisition  form.  A  single  agency-wide  system  processes  over  15  million 
requisitions  a  year.  A  second  agency-wide  system,  implemented  between  1986  and  1988, 
administers  200,000  contracts.  As  a  result  of  these  common  systems,  both  part  number  and 
contractor  are  standardized  and  shared  on  all  systems. 

Even  though  LSA  has  implemented  a  few  agency-wide  standards,  systems 
development  remains  quite  decentralized.  One  early  planning  effort  attempted  to  coordinate 
and  prioritize  requests  for  new  systems  on  an  agency-wide  basis.  The  functional  groups, 
which  felt  they  lost  the  ability  to  support  their  own  needs,  resisted  the  process.  After  a 
two-year  existence,  the  Agency-Wide  Application  Development  List  was  replaced  by  a  series 
of  discussions  between  the  director  and  each  functional  group  on  priorities  in  that  area. 
Thus,  the  interdependent  "agency-wide"  nature  of  systems  prioritization  has  been  removed, 
giving  functional  areas  more  decentralized  control  over  their  systems. 

Motivations/Goals  for  the  SDP.  A  second  planning  effort  at  LSA,  the  focus  of  this 
study,  began  in  1979  when  IS  requested  sizeable  funds  to  upgrade  its  computing  facilities. 
Authorization  was  given  in  1979  but  LSA  took  no  action,  due  to  internal  disagreements 
about  the  degree  of  centralization  of  the  new  hardware.    In  1983  the  authorization  was 
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withdrawn,  the  argument  being  that  the  request  for  funds  should  be  functionally  driven,  and 
that  the  organization,  not  simply  the  hardware,  should  be  modernized.  IS  made  several 
attempts  to  incorporate  a  functional  perspective,  but  these  were  criticized  as  being  too 
technical  and  too  fragmented.  In  1985  IS  turned  to  the  Plans  and  Policies  group  within  LSA 
for  help.  This  group  initiated  a  strategic  planning  process  using  a  methodology  derived  from 
Martin's  (1982)  approach.  The  objective  was  to  plan  a  set  of  integrated  systems  across  the 
agency. 

Highlights  of  the  Planning  Process.  Early  in  the  planning  process,  seventeen  business 
areas  were  identified.  Of  these,  nine  were  classified  as  essential  to  LSA's  external  mission 
and  nine  groups  of  individuals  were  formed  to  analyze  these  critical  business  areas.  Each 
group  consisted  of  12  to  15  people,  with  a  full  time  commitment  of  about  ten  weeks,  as 
shown  in  Table  2. 

Data  modeling  was  by  far  the  largest  single  component  of  the  planning  effort.  It 
averaged  between  70  and  80  percent  of  the  person  hours  spent  on  all  analysis  activities,  with 
some  participants  working  a  considerable  number  of  overtime  hours  formulating  and  revising 
the  models.  In  spite  of  this  effort,  some  team  members  felt  that  time  simply  ran  out  before 
the  models  were  stabilized.  There  was  a  concern  among  participants  that  the  resulting 
models  might  not  be  correct  enough,  or  detailed  enough  to  be  useful.  The  level  of  detail 
and  quality  of  the  plans  and  documents  were  also  not  consistent  across  groups. 

Results  of  the  SDP.  Given  that  the  documents  were  inconsistent  and  that  they  were 
too  voluminous,  technical,  and  detailed  for  management,  a  summary  set  of  documents  was 
prepared,  written  in  a  non-technical  fashion  (eliminating  all  data  models)  and  focusing  on 
the  business  area  critical  success  factors.  These  summary  documents  were  then  pulled 
together  into  an  agency-wide  Concept  Paper,  which  addressed  business  initiatives,  data 
support  requirements,  and  system  support  requirements. 

The  SDP  effort  was  considered  successful  by  its  participants.  However,  the  cabinet 
department  to  which  LSA  reports,  while  praising  the  Concept  Paper  as  the  best  document 
of  its  type  it  had  ever  seen,  also  criticized  it  as  being  too  big  and  complex  to  serve  as  a  basis 
for  a  funding  request,  suggesting  it  be  broken  down  to  make  it  more  manageable.  Within 
LSA,  some  groups  have  argued  that  the  plan  does  not  provide  enough  detailed  information 
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Table  2.  Time  and  Cost  Estimates  for  the  SDP  Efforts  Studied. 

Organization 

Number  of 
Participants 

Percent  of 
Full  Time 

Duration 

Estimated 
Cost* 

LSA 

9  teams  of 
12-15  each 

100% 

10  weeks 

$1,900,000 

Ventura  Finance 

15 

50-60% 

9  months 

500,000 

Ventura  SSD 

15 

50% 

9  months 

450,000 

Cedar 

10 

100% 

1  year 

800,000 

Costs  are  estimated  by  assuming  an  average  salary  of  $40,000  and  overhead  and  fringe  benefits  of 
100%. 
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to  serve  as  a  basis  for  rebuilding  systems.  Within  the  functional  areas,  the  Concept  Paper 
has  been  interpreted  as  a  document  which  sets  functional  goals  and  provides  overall 
direction  for  LSA  systems.  Each  of  the  functional  areas,  however,  is  in  the  process  of 
designing  and  implementing  modernization  efforts  in  its  own  area,  without  any  centralized 
coordination. 

Two  years  after  the  final  Concept  Paper  was  completed,  the  Policy  and  Plans  group 
that  championed  the  SDP  continues  to  struggle  to  keep  its  vision  of  totally  integrated 
databases  alive,  with  significant  organizational  political  pressures  from  a  new  LSA 
Modernization  project  management  group.  Funding  to  bring  all  the  data  models  from  the 
original  SDP  to  a  uniform  level  has  not  been  forthcoming.  In  an  effort  to  demonstrate  the 
benefits  of  shared  data,  the  SDP  group  has  focused  on  a  specific  project  -  a  Contractor 
Information  system.  After  great  difficulty  with  funding  and  people,  they  are  finally  off  the 
ground.  However,  the  fate  of  the  project  is  unclear,  as  the  champion  of  the  SDP  effort  is 
set  to  retire. 

Cases  #2  and  #3:   Ventura  Products 

Background.  Two  case  studies  were  conducted  at  Ventura  Products:  one  at  the 
Finance  Division  and  one  at  the  Support  and  Service  Division.  Ventura  Products  has  annual 
sales  exceeding  one  billion  dollars.  It  manufactures  and  distributes  consumer,  health  care, 
and  industrial  products.  Though  Ventura  is  quite  decentralized,  it  maintains  centralized 
control  in  some  areas.  Customer  accounts  and  assets  are  centrally  controlled  and  managed, 
but  the  individual  divisions  are  responsible  for  product  development  and  marketing. 

Corporate  IS  (CIS)  supports  the  centralized  functions  by  maintaining  a  number  of 
core  systems,  such  as  billing,  accounting,  payroll,  and  purchasing,  which  are  used  by  all 
divisions.  The  divisions  and  large  departments,  in  turn,  have  local  IS  units  to  develop  and 
support  their  local  IS  activities.  There  is  a  formal  group  within  CIS  that  is  responsible  for 
maintaining  and  facilitating  their  in-house  version  of  SDP. 

Ventura  Finance  Division  (Case  #2).  Background.  The  Finance  Division  at  Ventura 
consists  of  four  departments:   Tax,  Controller,  Internal  Auditing,  and  Treasurer.  Finance 

13 


is  large,  employing  over  1000  individuals,  over  60  of  whom  are  IS  personnel.  The  annual 
budget  for  IS  exceeds  $17  million. 

Motivations/Goals  for  the  SDP.  The  Finance  organization  had  been  affected 
significantly  by  changes  in  government  regulations,  technology,  and  legal  requirements. 
Partly  because  of  this,  the  IS  organization  tended  to  be  reactive  to  day-to-day  crises,  rather 
than  to  follow  a  long-term  plan.  The  result  was  problems  with  incompatible  data  across 
systems  and  spiralling  costs.  Finance's  IS  steering  committee,  which  included  key  senior 
managers  from  the  function,  realized  that  they  could  no  longer  afford  to  operate  without  a 
long  term  vision.  They  were  searching  for  a  way  to  articulate  their  future  needs  and  at  the 
same  time  to  develop  some  standards  and  guidelines  that  would  move  them  toward  a  more 
planned  environment  where  resources  could  be  allocated  in  a  logical  manner. 

After  the  SDP  group  from  corporate  IS  gave  a  presentation  on  SDP  as  a  solution, 
the  Finance  IS  steering  committee  was  at  first  split  on  whether  to  undertake  the  effort. 
However,  one  of  the  Finance  managers  on  the  committee  had  seen  the  positive  effects  of 
a  BSP  in  his  own  organization  years  ago  and  he  persuaded  the  group  to  charter  the  SDP. 
In  sum,  the  goal  of  the  effort  can  be  described  as  providing  an  overall  plan  and  architecture 
for  guiding  the  systems  development  process  and  developing  a  better  way  to  identify  and 
prioritize  new  systems  projects. 

Highlights  of  the  Planning  Process.  The  time  and  effort  statistics  of  the  Finance  SDP 
are  shown  in  Table  2.  During  the  planning  effort,  the  participants  quickly  realized  that  the 
SDP  methodology  as  recommended  was  problematic  for  their  organization.  The  Finance 
division  is  a  staff  function  that  supports  the  entire  organization.  Since  the  division  creates 
and  manipulates  so  much  of  the  organization's  data,  following  the  SDP  methodology  would 
produce  a  volume  of  information  the  planning  participants  could  not  possibly  cope  with. 
They  tried  to  manage  the  scope  of  their  planning  effort  by  limiting  the  number  of  business 
functions  analyzed  to  forty,  but  they  still  had  to  operate  at  a  much  higher  level  of  detail  than 
called  for  by  the  SDP  methodology.  As  a  result,  they  were  not  able  to  identify  specific 
applications  for  future  development,  or  to  create  detailed  architectures  or  plans.  Instead, 
they  created  two  products  which  might  be  loosely  called  architectures.   The  first  was  the 
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identification  of  11  "logical  locations"  or  groupings  of  data  elements4  which  provided  a 
conceptual  map  of  the  data  of  the  organization,  and  allowed  them  to  categorize  many  actual 
and  potential  systems  projects  in  a  useful  and  meaningful  manner.  The  second  product  was 
a  set  of  18  high-level  recommendations  and  development  guidelines.  The  generality  and 
level  of  detail  of  these  guidelines  is  indicated  by  the  examples  reproduced  in  Table  3.  In 
addition,  the  final  plan  describes,  on  a  broad  level,  upgrades  for  existing  systems  and 
development  of  new  systems  that  will  enable  the  division  to  meet  their  business  needs. 

Results  of  the  SDP.  Below  these  top  level  recommendations,  the  expectation  is  that 
each  department  within  Finance  will  carry  out  its  own  modified  planning  efforts,  filling  in 
the  details  of  the  Finance  SDP  by  identifying  and  prioritizing  specific  applications  and 
constructing  a  data  model  for  their  department.  Finance  will  then  consolidate  these  plans 
for  the  entire  division. 

While  they  experienced  a  number  of  problems  with  the  methodology  itself,  the 
Finance  team  members  cite  several  benefits  from  participating  in  the  SDP.  First,  they 
believe  that  they  will  save  money  over  the  long  run  since  the  development  of  systems  will 
be  managed  better  as  the  new  "architectural"  guidelines  are  followed.  Second,  the  team 
members  note  that  communication  improved  between  CIS  and  Finance,  and  among 
individual  Finance  departments.  This  helped  to  decrease  feelings  of  provincialism:  "Eight 
directors  found  out  that  they  are  managing  corporate  data,  not  their  own  data.  This  was  a 
big  change  in  attitude  among  the  directors."  Thus,  communication  and  education  benefits 
were  also  achieved. 

Ventura  Support  and  Service  Division  (Case  #3).  Background.  The  Support  and 
Service  Division  (SSD)  is  a  large  service  division  within  Ventura  and  employs  more  than 
1000  people  in  the  U.S.,  including  fifteen  IS  employees  and  twenty-five  IS  contractors.  This 
division  was  created  from  a  number  of  smaller  groups,  each  with  its  own  IS  perspective. 
From  1979  to  1982,  Ventura  pulled  all  of  these  areas  into  SSD  so  that  service  contracts 


The  11  logical  locations  are:  consulting,  administration,  customer  related,  risk  management,  auditing, 
employee  related,  amortized/depreciated  assets,  vendor  related,  inventory,  reporting,  and  finance. 
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Table  3.  Excerpts  from  Ventura  Finance's  Strategic  Information  Plan. 


Recommendations: 

1.  We  recommend  that  a  Data  Resource  Manager  (DRM)  be  appointed  for  the 
Finance  Organization.  The  DRM  would  be  responsible  for  integration  of  data  at  the 
organization  level. 

2.  We  recommend  that  all  future  system  designs  in  the  Finance  Organization 
consider  the  following  features  where  applicable:   mass  update  capability, 
upload/download,  special  reporting,  decision  support  capability. 

3.  We  recommend  that  documentation  and  programming  standards  should  be 
adopted  by  all  departmental  I/S  support  groups  if  they  have  not  already  done  so. 

4.  We  recommend  that  a  Post  Implementation  Plan  be  adopted  to  insure  the 
continued  progress  toward  the  goals  established  during  the  SDP  process. 


Source:      Finance  Organization  Strategic  Information  Planning  Study  Final  Report, 
December,  1987. 
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could  be  managed  at  the  corporate  level.  It  required  five  or  six  years  to  stabilize  the  division 
and  define  its  business  mission.  During  this  period,  IS  was  not  a  priority. 

Motivations/Goals  for  the  SDP.  However,  once  SSD  emerged  with  a  clear  mission, 
IS  was  recognized  as  a  critical  success  factor.  Management  saw  that  SSD  must  shift  from 
a  focus  on  product  models  and  serial  numbers  to  a  focus  on  customers.  They  explicitly 
recognized  that  easily  accessible,  accurate  information  about  service  requests,  equipment 
histories,  etc.  was  critical  if  they  were  to  succeed.  Their  existing  systems  (pulled  from 
various  predecessor  organizations)  did  not  support  this  new  focus,  and  suffered  from 
important  data  integrity  problems.  Thus  there  was  strong  management  agreement  on  the 
need  for  new  systems  to  support  the  new  business  context.  One  individual  in  particular 
championed  SDP  as  a  means  of  moving  away  from  a  piecemeal  development  mentality  to 
an  environment  of  planned  development,  giving  SSD  the  ability  to  take  advantage  of 
strategic  opportunities. 

Highlights  of  the  Planning  Process.  The  time  and  effort  statistics  for  the  SSD  SDP  are 
shown  in  Table  2.  During  the  SDP,  approximately  sixty  business  functions  and  twenty  data 
entities  were  identified,  and  a  detailed  data  model  developed.  The  effort  also  produced  a 
migration  plan  for  moving  from  its  mixed  vendor  environment  to  a  single  vendor,  and  a 
Gantt  chart  prioritizing  the  upcoming  development  projects. 

Results  of  the  SDP.  Two  systems  will  create  the  bulk  of  the  data  used  by  the  division. 
Implementation  of  the  first  of  these,  the  Revenues  system,  began  soon  after  the  SDP  was 
completed.  The  Revenues  project  manager  acknowledged  the  value  of  the  work  previously 
done  by  the  SDP.  However,  he  noted  that  the  development  team  had  to  do  a  substantial 
amount  of  rework  to  create  a  useable  data  model  because  of  a  number  of  inaccuracies  in 
the  one  created  by  the  planning  participants.  He  indicated  that  a  data  model  at  a  higher 
level  and  more  approximate  than  the  one  produced  by  the  SDP  would  have  been  as 
valuable:  "We  are  the  experts,  not  the  people  doing  the  SDP.  We  have  to  sort  out  and 
correct  the  errors  made  by  the  SDP  people  anyway." 

During  the  development  of  the  Revenue  System,  the  SSD  division  worked  hard  and 
long  to  reconcile  the  definition  and  name  of  each  of  Revenue's  500  data  elements  with  the 
several  thousand  standard  data  definitions  already  on  Ventura's  corporate  data  dictionary. 
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This  was  a  major  time  commitment,  and  required  help  from  the  corporate  data  standards 
group.  In  spite  of  all  of  this  effort,  SSD's  data  resource  manager  believes  SSD  and  the 
corporate  data  dictionary  have  some  "near  duplicates." 

Interestingly,  SSD  is  not  following  this  process  for  the  development  of  its  second 
major  system,  Logistics,  since  it  required  too  much  time  and  money  for  Revenues.  SSD  does 
not  feel  that  the  inconsistencies  between  their  systems  and  corporate  data  standards  will 
cause  them  problems. 

SSD  considered  the  planning  process  quite  successful,  and  felt  the  final  plan  was 
useful  and  beneficial.  Unfortunately,  current  business  pressures  threaten  to  slow  down  the 
implementation  of  the  remaining  systems  identified  in  the  SDP. 

Case  #4:   Cedar  Industries 

Background.  Cedar  markets  a  wide  range  of  products  and  services  to  businesses  and 
consumers.  Located  in  the  Southwest,  the  organization  is  a  major  player  in  an  industry  that 
was  gradually  deregulated  during  the  1980s.  As  the  industry  deregulated,  Cedar  Industries 
experienced  a  major  upheaval  in  its  structure,  culture,  and  business. 

With  the  reorganization  that  followed  deregulation,  many  previously  separate  divisions 
needed  to  coordinate  in  new  ways  but  incompatible  information  systems  made  this 
impossible.  The  resulting  operational  paralysis  motivated  top  management  to  address  the 
underlying  problem  as  well  as  to  solve  the  immediate  crisis.  Both  a  high  level  task  force  and 
an  outside  consulting  firm  strongly  advised  establishing  an  information  executive  and 
managing  the  data  infrastructure. 

Motivations/Goals  for  the  SDP.  As  part  of  the  recommendations,  divisions  were 
encouraged  to  use  SDP  in  their  IS  planning  efforts.  As  IS  groups  were  gradually 
reorganized  into  a  single  CIO  organization,  a  special  group  was  established  to  encourage  and 
assist  the  divisions  in  carrying  out  a  new  in-house  strategic  systems  planning  methodology. 
This  methodology  was  intended  to  surface  the  critical  data  used  in  running  the  business;  to 
provide  a  framework,  or  architecture,  around  which  future  systems  would  be  built;  as  well 
as  to  identify  key  strategic  systems. 

In  part  because  its  vice  president  was  sold  on  the  importance  of  managing  data,  one 
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of  the  first  groups  to  use  this  new  methodology  was  the  consumer  services  division. 

Highlights  of  the  Planning  Process.  The  time  and  effort  statistics  of  the  consumer 
services  division's  SDP  are  shown  in  Table  2.  A  very  detailed  business  model  was  developed 
with  16  business  functions  broken  down  into  88  processes  and  530  activities.  For  each 
activity,  the  data  entities  used  as  input  and  output  were  identified.  In  addition,  20  to  40 
different  user  types  were  identified,  and  both  the  type  and  location  of  users  were  associated 
with  each  of  the  530  activities.  This  business  modeling  process  took  six  months,  or  one-half 
of  the  total  time.  Ten  projects  were  identified,  four  of  which  were  selected  for  the  tactical 
phase,  and  three  of  these  were  ultimately  implemented. 

Results  of  the  SDP.  The  SDP  has  also  provided  this  division  of  Cedar  with  an 
architecture  that  will  guide  its  future  systems  development.  The  architecture  takes  the  form 
of  200  or  so  "business  modules"  or  groupings  of  the  530  activities,  and  40  data  entities. 
Whenever  a  new  business  requirement  surfaces,  this  can  be  located  in  the  architecture,  and 
Cedar  can  decide  where  it  is  most  beneficial  to  place  the  process.  Instead  of  building  it  as 
a  separate  isolated  process,  they  might  fold  it  into  a  major  enhancement,  so  as  to  build  a 
piece  of  the  architecture. 

While  this  SDP  effort  was  considered  a  success,  fewer  and  fewer  other  divisions  at 
Cedar  are  willing  to  use  the  approach.  Even  the  business  manager  who  presided  over  the 
successful  effort  admitted  that  he  probably  would  not  spend  that  kind  of  money  if  he  had 
it  to  do  over  again.  His  primary  reason  is  that  the  process  takes  too  long,  costs  too  much, 
and  does  not  seem  to  produce  that  much  better  a  plan.  This  sentiment  was  echoed  by 
several  managers  responsible  for  authorizing  and  funding  development  efforts  in  other  parts 
of  Cedar. 

One  such  manager  suggested  that  the  SDP's  biggest  problem  was  that  it  did  not  focus 
on  anyone's  number  one  problem,  that  it  ended  up  surfacing  everyone's  second  priority 
problems.  This  manager  thought  the  value  might  be  greater  for  a  firm  where  the  IS  function 
was  centralized,  and  operates  in  a  reactive  mode  to  requests  from  the  business.  The 
educational  value  to  IS  in  such  a  firm  might  make  the  process  worthwhile. 

A  number  of  other  concerns  were  raised  about  SDP.  First,  the  demanding  time 
requirements  of  the  SDP  may  result  in  the  selection  people  who  take  too  much  for  granted 
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and  are  not  likely  to  be  useful  at  creatively  ^thinking  and  redesigning  the  business 
processes.  Second,  some  critical  needs  surface  early  in  the  SDP  process  and  are  immediately 
acted  upon  unilaterally  by  functional  management  long  before  the  plan  is  completed.  Thus, 
with  action  in  progress  on  some  of  the  highest  business  priorities,  there  are  fewer  compelling 
arguments  for  implementing  the  total  program.  Third,  the  ability  to  communicate  the  plan 
to  the  systems  development  department  may  prove  problematic.  The  several  systems 
analysts  interviewed  were  not  aware  of  any  guidance  or  constraints  on  their  activities  that 
resulted  from  the  SDP.  However,  it  is  possible  that  these  analysts  were  at  too  low  a  level 
in  the  organization  to  be  aware  of  the  impacts  of  the  SDP. 
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DISCUSSION 

These  four  cases  illustrate  that  a  strategic  data  planning  effort  is  a  major,  complex 
undertaking  and  that  there  are  many  managerial  issues  to  consider.  As  Table  2  shows,  all 
four  were  quite  expensive,  typically  costing  around  half  a  million  dollars,  and  taking  from  6 
to  12  months.  Their  initial  planning  objectives  were  different  and  the  outcomes  varied,  as 
summarized  in  Table  4.  The  outcomes  achieved  were  not  necessarily  the  goals  initially 
aimed  for. 

The  reasons  why  SDP  methods  are  difficult  to  implement  listed  in  Goodhue  et  al. 
(1988)  hold  true  for  these  additional  companies.  (See  Sidebar  #2.)  There  are,  however, 
deeper  insights  to  be  gained  when  we  use  the  five  "potential  outcomes"  presented  earlier  to 
organize  our  analysis.  What  are  the  lessons  to  be  learned  from  these  companies  about  using 
an  SDP  method  to  achieve  "totally  integrated  systems"  or  to  "identify  business  opportunities", 
etc.?  How  effective  are  SDP  methods  in  achieving  these  outcomes?  Based  on  these  cases 
and  the  research  we  have  conducted  over  the  past  five  years  on  data  management,  the  rest 
of  this  paper  discusses  the  issues  we  see  that  affect  the  success  of  an  SDP  effort  and 
proposes  directions  for  future  research. 

Goal  #1.   Building  a  Totally  Integrated  Systems  Environment 

For  most  firms,  achieving  this  outcome  in  the  near  term  implies  a  nearly  total  rewrite 
of  all  systems.  For  firms  desirous  of  this  outcome  and  willing  to  pay  the  cost,  Martin's 
comment  is  probably  quite  accurate:  "It  would  be  unthinkable  to  build  a  battleship  without 
an  overall  plan  of  the  whole  ship"  (1982,  p.  1).  It  can  be  argued  that  the  SDP  methodology 
is  in  many  respects  a  design  methodology,  as  well  as  a  planning  methodology.  It  rests  on  an 
implicit  assumption  that  all  systems  in  the  domain  are  being  re-designed,  and  it  actually 
starts  the  process  of  systems  design.  This  is  appropriate  when  all  systems  in  the  planning 
domain  will  probably  be  redesigned. 

Many  firms  are  not  prepared  to  undertake  the  cost  of  a  total  re-design  effort  to 
achieve  a  totally  integrated  environment.  Where  total  system  re-design  is  not  intended, 
much  effort  in  an  SDP  goes  into  the  initial  design  of  systems  that  will  not  be  built.  Because 
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1                                        I 

Table  4:  Original  Objectives  and  Outcomes  Achieved 

LSA 

Ventura 
Finance 

Ventura 
SSD 

Cedar 

Totally  Integrated  Systems 

* 

*  + 

Data  Architecture 

*  + 

+ 

*  + 

Identify  Systems  Priorities 

+ 

* 

+ 

*  + 

Rethink  Business  Processes 

Education/Communication 

+ 

+ 

+ 

+ 

Legend:    *  =  original  objective;    +  =  outcome  achieved 

22 


of  this,  we  argue  that  the  SDP  methodology  is  really  tuned  best  for  the  very  ambitious 
objective  of  totally  integrated  systems. 

However,  even  when  a  total  systems  rewrite  is  intended,  the  inaccuracies  in  the  data 
model  at  Ventura  SSD  suggest  a  possible  problem: 

SDP  Spends  Too  Much  Time  Bringing  Novice  Data  Modelers  Up  the  Learning  Curve. 
A  substantial  portion  of  the  total  planning  time  is  spent  in  data  modelling,  generally  by  team 
members  who  are  not  expert  data  modelers.  Thus,  a  time-consuming  and  complex  process 
is  made  more  so  by  giving  it  to  people  who  are  not  expert  in  the  concepts  or  techniques 
required.  This  may  provide  useful  education  to  team  members,  but  is  not  an  efficient  means 
of  developing  an  accurate  data  model. 

Although  SDP  is  often  sold  on  the  basis  of  integrating  the  data  of  the  firm,  and  two 
of  the  planning  efforts  in  our  cases  explicitly  sought  this  goal,  as  Table  4  illustrates,  only 
Ventura  SSD  seems  to  be  succeeding  at  this  goal.  What  explains  the  difficulties  encountered 
by  the  other  cases  or  the  success  at  SSD?  Our  research  to  date  suggests  there  are  at  least 
three  ingredients  that  are  critical  to  successfully  completing  an  SDP  and  implementing  the 
resulting  totally  integrated  systems: 

Data  Integration  Must  be  Critical  to  Top  Management.  While  many  researchers  have 
suggested  that  top  management  involvement  is  critical  to  the  success  of  an  SDP,  we  argue 
that  involvement  alone  is  not  enough.  Top  management  was  involved  enough  in  all  four 
case  studies  to  fund  the  planning  effort,  and  give  it  at  least  nominal  support.  But  only  at 
Ventura  SSD  did  management  see  data  sharing  between  systems  as  critical  to  the  success 
of  its  strategy  for  the  organization.  For  SSD,  strategic  data  planning,  though  expensive,  was 
considered  essential.  Where  data  sharing  is  not  critical  to  top  management's  view  of  the 
future  organization,  they  are  unlikely  to  allocate  the  necessary  resources  for  the  major 
system  rewrites  required. 

Sufficient  Control  over  the  Planning  Domain  is  Needed.  An  organization  must  have 
sufficient  control  over  the  planning  domain  to  resolve  conflicts  among  the  organizational 
subunits  involved.  Whether  the  resolution  is  achieved  through  centralized  authority  or 
negotiated  consensus,  agreements  must  be  forged  on  the  tough  design  issues  that  may 
adversely  affect  some  parties.  An  SDP  may  well  be  seen  as  a  threat  to  decentralized  power. 
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For  example,  in  the  LSA  organization,  the  failure  of  the  Agency-Wide  Application 
Development  List  was  at  least  partially  a  result  of  functional  areas  resisting  a  loss  of  local 
autonomy  and  control.  The  later  SDP  was  allowed  to  proceed,  but  its  results  were  quickly 
co-opted,  and  the  organizational-wide  effort  never  gained  momentum. 

The  Scope  Must  be  Manageable.  Large  organizations  may  have  trouble  adapting  the 
methodology  to  their  needs.  As  suggested  at  Cedar,  when  the  scope  is  too  large,  planners 
may  get  lost  in  the  crush  of  detail.  When  large  planning  domains  are  broken  into  pieces, 
as  at  LSA  uneven  quality  and  level  of  detail  may  make  it  difficult  to  consolidate  separate 
pieces.  On  the  other  hand,  using  the  methodology  with  a  less  detailed  level  of  analysis,  as 
Ventura  Finance  did,  may  result  in  relatively  superficial  plans. 

Goal  #2.   Creating  a  Data  Architecture 

An  SDP  offers  the  promise  of  producing  a  data  architecture  to  guide  systems 
development  so  that  as  new  applications  are  built  and  old  systems  revised,  the  firm  will 
gradually  move  toward  a  set  of  integrated  applications  and  databases.  The  case  studies 
reported  here  suggest  several  key  issues  for  the  successful  use  of  a  data  architecture. 

Vie  Most  Appropriate  Form  for  a  Data  Architecture  is  Not  Clear.  Typically,  the 
architecture  produced  by  an  SDP  takes  the  form  of  a  matrix  of  data  entities  and  processes, 
grouped  into  logical  systems  or  business  modules.  Other  possible  forms  of  data  architectures 
(not  necessarily  developed  using  SDP)  are  a  detailed  corporate  data  model,  or  a  collection 
of  standard  data  definitions  for  critical  data  elements.  Because  of  a  lack  of  industry 
experience,  it  is  not  yet  clear  what  is  the  most  appropriate  form  of  data  architecture  for  long 
term  integration.  Once  the  most  appropriate  form  is  determined,  we  must  ask  whether  the 
SDP  is  the  most  cost  effective  means  of  developing  it.  At  Cedar  Industries,  though  they 
realized  value  from  an  architecture  of  200  business  modules  produced  by  an  SDP,  they 
considered  the  SDP  too  expensive  to  justify  its  use  in  other  areas.  At  Ventura  Finance,  it 
would  seem  possible  to  identify  eleven  "logical  locations"  at  far  less  than  the  cost  of  the  SDP. 

An  Architecture  Must  Balance  Global  Integration  and  Local  Flexibility.  To  be  effective, 
a  data  architecture  must  find  the  right  balance  between  the  value  of  global  data  integration 
versus  local  flexibility  (Goodhue  1989).    At  LSA  where  there  is  already  in  place  some 
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"partial"  data  integration  in  the  form  of  common  definitions  and  codes  for  all  part  numbers 
and  for  all  contractors,  the  additional  value  of  more  global  data  integration  was  not 
compelling  to  the  decentralized  divisions.  They  preferred  rapid  local  solutions  to  the  issues 
raised  by  the  SDP,  rather  than  waiting  an  indeterminate  time  for  a  global  solution,  and 
possibly  losing  control  of  the  solution's  details.  One  interpretation  would  be  that  the  current 
architecture  of  "partial"  data  integration  (part  numbers  and  contractor  ID's)  already  strikes 
approximately  the  right  balance  between  global  and  local  needs  for  this  decentralized 
organization. 

The  partial  architecture  currently  in  place  at  LSA  is  not  consistent  with  the 
philosophy  of  the  SDP  which  assumes  that  the  balance  between  global  data  integration  and 
local  flexibility  is  tilted  much  more  toward  global  integration.  Thus  using  SDP  for 
developing  a  data  architecture  may  be  inappropriate  in  more  decentralized  organizations. 

Architectures  Must  Be  Enforced.  Whatever  form  the  data  architecture  takes,  it  must 
be  enforced  or  systems  developers  will  not  conform  to  it,  and  it  will  have  no  effect  on 
systems.  For  example,  at  Ventura  the  corporate  data  standards  effort  defined  an 
architecture  of  several  thousand  standardized  data  elements.  However,  systems  developers 
in  the  SSD  division  decided  against  conforming  to  this  architecture  for  their  Logistics  system, 
because  of  the  additional  local  cost. 

If  the  goal  of  an  SDP  is  a  data  architecture,  a  great  deal  more  attention  should  be 
paid  to  the  most  appropriate  form  of  the  architecture,  and  how  that  architecture  will  interact 
with  the  systems  development  process. 

Architectures  Should  Be  "Stolen"  Not  Recreated.  Martin  suggests  that  a  basic  principle 
of  information  engineering  should  be  "steal  don't  reinvent"  (1986,  p.  68).  Where  possible, 
the  same  should  apply  to  data  architectures.  To  the  extent  that  data  architectures  are  stable 
over  time  within  a  company,  they  should  also  be  quite  similar  across  companies  within  an 
industry.  Goodhue  et  al.  (1988)  reported  that  in  one  company  a  data  model  developed  in 
one  division  was  adopted  by  another  division  with  minor  changes  and  successful  results. 
Though  none  of  the  case  studies  reported  here  "borrowed"  their  data  model  from  a  similar 
organization,  perhaps  companies  should  consider  this  as  an  option. 
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Goal  #3.   Identifying  Systems  Priorities 

Totally  integrated  systems,  in  either  the  short  or  long  term,  are  not  the  only  possible 
outcome  of  an  SDP.  Another  goal  could  be  identifying  potential  systems  projects  for  the 
organization  and  prioritizing  these  for  near  term  implementation.  However,  we  argue  that 
SDP  is  not  an  efficient  approach  for  this  goal  by  itself,  since  it  does  not  narrow  its  scope  fast 
enough  before  it  begins  the  time  consuming  charting  of  processes  and  entities. 

Return  for  a  moment  to  Martin's  (1982)  metaphor  of  building  a  battleship  without 
a  complete  set  of  overall  plans.  Suppose  that  rather  than  building  from  scratch,  the  goal  is 
to  repair  or  modernize  an  existing  ship.  It  is  clear  that  some  overall  map  of  the  total  ship 
is  critical  to  understand  how  the  targeted  high  payoff  projects  fit  into  the  whole.  But  if 
identifying  high  payoff  projects  is  the  goal,  relatively  less  time  should  be  spent  on  the  overall 
map,  so  that  planners  can  more  quickly  focus  on  critical  areas.  For  these  purposes,  the 
detail  and  expense  of  an  SDP  is  overkill  --  detailed  plans  are  not  needed  for  major  portions 
of  the  ship.   SDP  thus  has  three  problems  when  used  to  identify  systems  priorities. 

Too  Much  Effort  is  Spent  "Desisting"  for  Non-Critical  Areas.  If  the  goal  is  identifying 
systems  priorities,  not  all  organizational  processes  or  data  entities  are  of  equal  importance. 
In  fact,  the  more  we  can  quickly  narrow  our  attention  to  those  systems  or  functions  which 
have  a  critical  business  impact,  the  sooner  that  impact  will  tell  for  us  in  competitive  position, 
or  bottom  line6.  However,  since  SDP  actually  begins  the  design  process  of  building  a  totally 
integrated  set  of  systems,  it  tends  to  give  each  process  and  each  entity  equal  weight.  When 
these  systems  aren't  going  to  be  built,  much  of  this  design  effort  is  wasted. 

Creativity  is  Swamped  by  the  Volume  of  Detail.  The  volume  of  detail  required  by  the 
methodology  (on  non-critical  as  well  as  critical  areas  of  the  business)  tends  to  swamp 
individuals'  abilities  to  see  the  whole  picture,  and  to  fashion  creative  solutions.  At  Cedar 
Industries,  the  SDP  team  spent  six  months  analyzing  530  business  activities,  specifying  for 
each:  the  data  entities  needed  for  input,  the  data  entities  produced  as  outputs,  the  user 


■*An  "80/20"  planning  approach  (Goodhue  et  al.,  1988)  which  quickly  established  a  rough  map  of  the  firm's 
data  would  be  a  far  better  starting  point  for  targeting  critical  systems. 

Critical  Success  Factors"  (Rockart,  1979)  is  one  planning  approach  that  far  more  rapidly  identifies  high 
payoff  projects. 
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types,  and  the  locations  used.  Though  the  team  identified  several  useful  projects  after  this 
data  modeling  effort,  user  managers  felt  the  projects  were  "everybody's  second  priority". 

The  Time  Required  by  Individuals  Self  Selects  the  Wrong  Participants.  The  SDP 
methodology  requires  as  much  as  half  a  year  of  effort  from  its  participants.  Since  the  time 
of  the  most  insightful  and  capable  individuals  is  usually  in  high  demand,  the  methodology 
tends  to  self  select  the  wrong  people  --  those  who  can  be  spared  because  they  are  not 
involved  in  other  critical  business  issues.  The  result  may  be  less  insightful  and  less  creative 
solutions. 

Goal  #4.   Rethinking  Business  Processes 

An  SDP  could  potentially  engender  a  new  perspective  on  the  business  by  focusing  on 
the  shared  data  of  the  enterprise.  None  of  the  four  cases  presented  had  this  as  an  explicit 
objective,  nor  achieved  the  outcome  of  rethinking  key  business  processes.  We  argue  that 
the  methodology  is  not  conducive  to  achieving  this  goal,  for  many  of  the  same  reasons  it  is 
not  appropriate  for  targeting  critical  systems. 

Rethinking  critical  business  processes  requires  managers  with  a  keen  understanding 
of  both  the  organization  and  the  business  environment,  and  an  ability  to  see  beyond  current 
ways  of  operating  --  exactly  the  kind  of  person  unlikely  to  be  able  or  willing  to  spend  major 
amounts  of  time  doing  detailed  modeling  of  hundreds  of  processes  or  activities.  Even  with 
the  right  participants,  the  emphasis  on  detailed  modeling  across  the  whole  scope  of  the 
planning  domain  may  bury  the  creativity  and  big  picture  thinking  needed  to  succeed. 

Goal  #5.  Promoting  Education  or  Communication 

Almost  every  SDP  effort  seems  to  have  clear  benefits  to  its  team  members  in  terms 
of  understanding  the  business  in  new  and  useful  ways.  This  may  be  one  of  the  most 
predictable  outcomes  of  the  process.  However,  there  are  several  important  concerns  here. 

The  New  Understanding  Seems  Difficult  to  Communicate.  In  reviewing  and 
synthesizing  the  planning  literature,  Boynton  and  Zmud  (1987)  note  the  importance  of  an 
"organizational  learning  analysis"  during  the  planning  process  to  assess  how  new  technologies 
will  be  accepted  and  institutionalized  throughout  the  organization.  The  research  presented 
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here  suggests  that  organizational  learning  is  not  always  a  by-product  of  SDP.  In  some  cases, 
team  members  report  that  their  new  insight  is  quite  compelling  to  themselves,  but  they  have 
great  difficulty  convincing  others,  including  top-level  management  and  the  participants'  peers. 
It  is  almost  as  if  each  person  must  go  through  the  SDP  initiation  themselves  before  they  "see 
the  light."  If  this  is  the  case,  SDP  is  a  very  expensive  technique  for  organizational  learning. 
The  Cost  of  an  SDP  Can  Probably  Not  be  Justified  by  Eduction  and  Communication 
Alone.  If  the  SDP  effort  can  be  justified  in  terms  of  some  combination  of  the  other  benefits, 
then  the  education/communication  benefit  may  be  a  bonus.  However,  from  these  cases  it 
seems  clear  that  education  alone  is  not  sufficient  justification  given  the  high  cost  of  the 
methodology.  Put  another  way,  if  education  and  communication  are  the  primary  goal,  there 
are  probably  other  less  expensive  approaches  available. 
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CONCLUSIONS 

Tying  together  some  of  the  above  insights,  SDP  seems  more  or  less  appropriate 
depending  on  the  business  environment  and  the  desired  outcomes  of  the  planning  effort. 
Because  of  its  expense  and  its  orientation  toward  total  integration,  SDP  seems  most 
appropriate  where  large  scale  data  integration  is  a  critical  business  requirement.  It  is  less 
appropriate  for  identifying  systems  priorities  or  rethinking  the  business,  because  the  large 
time  requirements  and  volume  of  detailed  modeling  make  it  difficult  to  get  the  participation 
of  those  key  managers  with  a  clear  understanding  of  both  the  organization  and  the  business 
environment.  Finally,  the  educational  benefits  of  SDP  efforts  may  have  limited  impact  and 
are  purchased  at  a  high  price. 

This  suggests  that  firms  should  clarify  their  goals  before  beginning  an  SDP. 
Unfortunately,  as  Sinclair  (1986)  observed,  few  organizations  articulate  their  planning 
objectives  before  engaging  in  various  IS  planning  approaches.  The  failure  to  articulate  what 
is  hoped  for  in  a  planning  effort  can  result  in  a  mismatch  between  what  the  chosen  planning 
methodology  can  achieve  and  what  the  organization  wants,  and  can  lead  to  wasted  resources 
and  poor  quality  plans. 

Directions  for  Future  Research 

This  study  also  suggests  at  least  three  directions  for  future  research.  These  are  briefly 
described  below. 

What  Are  the  Most  Effective  Forms  of  Data  Architectures,  and  How  Can  Firms  Enforce 
Them?  While  there  are  a  few  studies  reporting  successful  implementations  of  architectures 
(e.g.,  Brancheau  and  Wetherbe  1986),  there  is  other  literature  that  suggests  that 
organizations  may  have  difficulties  implementing  data  architectures  because  they  lack 
experience  in  this  area  (e.g.,  Wardle  1984),  because  systems  development  activities  are 
becoming  more  dispersed  throughout  the  organization  making  it  more  difficult  to  control  and 
coordinate  individual  efforts  (e.g.,  Gillenson  1985),  and  because  systems  developers  may 
resist  changing  the  way  they  currently  build  and  implement  systems  (e.g.,  Goodhue  et  al. 
1988;  Gillenson  1985;  Shah  1984). 
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For  architectures  to  successfully  move  the  organization  to  a  desired  level  of  data 
integration,  there  must  be  some  mechanism  to  constrain  systems  developers  to  adhere  to  the 
standards  and  policies  articulated  in  them.  We  propose  that  organizational  units  responsible 
for  developing  and  implementing  architectures  must  have  sufficient  authority  and  clout  to 
enforce  them.  Furthermore,  these  units  must  be  able  to  monitor  the  development  process 
and  to  reward  developers  who  adhere  to  the  architectures. 

Are  Large  Organizations  Too  Complex  For  A  Single  Integrated  Data  Model?  The  results 
from  this  research  suggest  that  many  planning  participants  are  overwhelmed  by  the  volume 
of  detail  in  the  data  modeling  steps,  in  spite  of  the  training  and  facilitation  they  may  receive. 
Automated  means  of  storing  and  manipulating  this  information  (e.g.,  CASE  tools),  may  be 
one  solution,  as  many  practitioners  now  suggest. 

Even  with  such  automation,  however,  it  is  possible  that  in  large  organizations  the 
complexity  of  the  data  and  all  its  possible  interactions  are  too  great  to  allow  a  single 
integrated  solution.  We  propose  that  as  the  size  and  complexity  of  organizations  increase, 
single  integrated  data  models  begin  to  push  against  the  limits  of  human  information 
processing  abilities.  This  suggests  that  some  amount  of  compartmentalization  (or 
hierarchical  decomposability,  Simon  1969)  and  non-integration  in  the  design  of  systems  may 
always  need  to  be  maintained. 

Are  There  Important  Costs  as  Well  as  Benefits  of  Data  Integration?  When  implemented 
fully,  SDP  serves  as  a  mechanism  for  integrating  the  data  of  an  organization.  However, 
these  case  studies  suggest  that  integration  may  not  always  be  a  desirable  outcome  in 
organizations.  LSA  resisted  the  centralized  control  implied  by  data  integration.  SSD 
resisted  the  cost  of  complying  with  corporate  data  standards.  Functional  managers  at  Cedar 
co-opted  individual  findings  and  developed  unilateral,  local  systems  to  address  them. 

Given  the  intuitive  appeal  of  the  integration  concept  and  the  flexible  access  to 
organizational  data  that  it  promises,  how  can  the  limited  interest  in  total  integration  through 
an  SDP  be  explained?  Are  managers  in  these  case  studies  destructively  subverting  valid 
goals  of  their  organization,  or  could  resistance,  as  Markus  (1983)  might  suggest,  be  a  useful 
clue  to  a  problem  with  the  total  integration  approach.  Under  what  conditions  is  integration 
desirable?  Is  the  need  for  global  coordination  and  interdependence  somewhat  antagonistic 
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to  the  need  for  local  flexibility  and  differentiation,  as  Lawrence  and  Lorsch  (1967) 
suggested?  How  should  organizations  decide  when  to  integrate,  and  how  extensively  to 
integrate?  What  are  the  alternative  strategies  for  achieving  integration?  Under  what 
conditions  might  they  be  more  or  less  appropriate? 

We  propose  that  only  when  relationships  between  organizational  units  are 
characterized  by  strong  interdependence  and  little  need  for  local  flexibility  and  autonomy 
will  firms  quickly  embrace  implementing  an  SDP  with  its  implied  total  data  integration. 
Furthermore  it  is  not  the  total  need  for  interdependence  that  operates  here,  but  the 
additional  need.  Where  existing  systems  already  contain  important  elements  of  data 
integration  (such  as  common  item  and  contractor  identifiers  at  LSA,  and  common  billing, 
and  purchasing  systems  at  Ventura)  the  pressure  for  additional  integration  is  much  blunted. 
SDP  and  total  data  integration  are  not  the  only  means  available  to  organizations  to  address 
internal  interdependencies  (Galbraith,  1973),  and  the  basis  on  which  organizations  choose 
between  these  alternatives  is  a  subject  of  interest  among  researchers  (Daft  and  Lengel,  1984; 
Conger,  1988).  Rather  than  being  generally  appropriate,  the  value  of  SDP  and  total  data 
integration  may  depend  on  many  organizational  and  environmental  characteristics. 
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